<TITLE>RCcomments -- /DesignIssues</TITLE>
<NEXTID 6>
<H1>Comments on ideas from <A NAME=2 HREF=http://zippy.lcs.mit.edu:8000/timbl/trip/AtMIT/Overview.html#4>Tim's MIT stay</A></H1>Library 2000: persistence of information is important. It's my most
important criterion for choosing the next office system: can you transfer
the data to it?<P>
Nice clean UDI camp: the UDI is a name for the query. If the query
can be derived from the name somehow, and without implying a particular
software tool to be used, so much the better. But think of persistence
of information: do you want names to be compatible with SQL for the
next century?<P>
Quoting scheme: see <A NAME=1 HREF=ProtocolProblems.html#2>proposal</A> .<P>
Commercial viewpoint: I hope this does not offend Brewster, but I
hope, probably in vain, that the commercialists will stay out of the
Web world. Selling information is like selling air and water to me,
though of course you need to pay the people who provide the information.
Your comment already points out some of the bad side-effects of selling
per access, or worse, tariffs per type of information or per item!
Like: today's newspaper is 10CHF because there is this item in it
which everyone wants to know about.<P>
Freezing queries: why do we need the distinction? Is a frozen copy
a query from a frozen data base or a stored copy of the results of
a live query? in the latter case, the UDI is just the UDI anyway.<P>
Date information: surely important, but if you query, say, libraries,
then it might be much more complex.<P>
Argo etc. Are there people interested in the consortium idea?<P>
On <A NAME=3 HREF=http://zippy.lcs.mit.edu:8000/timbl/trip/AtMIT/UPenn/Meeting.html>Argo requirements</A> :<P>
Form filling: here we go into a real can of  horrible worms. I think
this is a perfect case for a next layer. The UDI will simply explode
and not live very long. See <A NAME=4 HREF=../Administration/DataModel.html#2>indirect nodes</A> .<P>
Multiple formats: of course, but the example is bad: surely one can
persuade the bus lines to provide the machine readable form somehow...(at
least in the future)<P>
Application launching: Yes.<P>
Complex interaction: the web should get you to the information, nothing
less but nothing more. Then one could launch an application based
on EDI to provide the bookstore's form and make the order.<P>
Client history: Maps are certainly needed.<P>
Client software update: notification of version differences does not
need to be part of the protocol, the version numbers fly across with
each access. Servers should never be concerned with versions of browsers,
(only of the HTTP protocol), Browsers can have very different functions
from one version to the next without using a different protocol version.
This is a non-issue.<P>
Forwarding: see <A NAME=5 HREF=../Administration/DataModel.html#2>indirect nodes.</A><P>
Native interfaces: the question is not so much whether that is powerful
enough as whether that is maintainable.<P>
Self-contained browser: true, but it makes for a big application,
and may not do as good a job as native converters which can be launched.
The configuration problem can certainly be solved, and it may be easier
than building and maintaining built-in format handling which may never
be completely compatible.<P>
<A NAME=0 HREF=http://info.cern.ch/hypertext/WWW/People.html#Cailliau>RC</A></A>